The Institute of Electrical and Electronics Engineers (IEEE) standard 802.11 is perhaps the most commonly implemented communications standard today in the context of wireless local area networks (WLANs). Various versions of and amendments to this standard have been published to date, including 802.11a, 802.11b, 802.11g, 802.11n, 802.11-2012, 802.1ac, 802.1ad, 802.1ah, etc. (collectively and individually “IEEE 802.11” or simply “802.11”).
Under 802.11, an access point (AP) transmits various management messages, called “frames,” to other wireless stations. One type of management frame is called a beacon frame, or simply “beacon.” Beacons are sent periodically by an AP to synchronize a wireless network. A beacon contains key information about the network, including a timestamp, the beacon interval, capability Information, service set identifier (SSID), supported rates, etc. The beacon identifies the presence of an AP, and clients and APs can maintain timing synchronization by using the time stamp in the beacon.
When a wireless station receives a beacon from another wireless station, its radio interface determines the received signal strength of the beacon, along with capability information and information regarding the network. In a network environment that includes multiple APs, a non-AP wireless station uses a received signal strength indicator (RSSI) and capability information to rank APs and decide which APs to attempt to use. An AP can use other APs' beacons to determine how many other APs are within communications range and which channels they use. An AP can also take into account other APs' information to select certain parameters, such as its channel of operation.
The beacon in 802.11 also supports use of power-saving mode by low-power clients, including battery operated devices. With infrastructure networks, an AP will buffer frames destined for sleeping stations and announce which clients have frames queued for them by use of a traffic indication map (TIM).
Under current implementations of 802.11, APs generally transmit beacons at intervals of approximately 100 ms or 200 ms. No channel reservation is done for purposes of sending beacons. Instead, 802.11 mandates use of a Carrier Sense Multiple Access/Collision Avoidance (CSMA/CA) algorithm for purposes of sending beacons and other messages. If another station is sending a frame when a beacon is to be sent, then the AP should detect this condition and “back off”, i.e., wait until the other station is done transmitting. Consequently, the actual time between two consecutive beacons may be longer than the beacon interval. CSMA/CA does not always work perfectly, however, and when it does not, beacons may collide with (i.e., temporally overlap) messages transmitted by other stations (including beacons of other APs). Additionally, the crystal oscillator used to derive the clock in an AP typically has some frequency drift, which can affect the timing of beacon transmissions and thereby contribute to beacon collisions with other messages.
Beacon collisions can have a significant impact on performance and power consumption and are therefore undesirable. When beacons from two APs collide, new clients may not be able to detect one or both of the APs. Further, clients that are already associated to an AP and are in the active state may not be able to synchronize themselves to the AP. Additionally, a client in power saving mode may have extra delays in receiving packets, may have to stay awake longer (e.g., to receive the beacon), and may even become disconnected from the AP and have to reconnect. Extra activity on the client side due to beacon collisions also consumes excess power on the client, which can be a significant issue for battery-operated (e.g., mobile) clients.
In addition to CSMA/CA and frequency drift, there are other known causes for beacon collisions, such as the so-called “hidden node” problem. Some APs may not be within wireless range of each other, yet there are clients that can detect the presence of both APs. As a result, the CSMA/CA back-off procedure employed by a given AP may not work in this situation. Additionally, some APs may be within range of each other but still may not detect another AP's beacon, due to fading or receiver failure, for example. Further, some APs have poor physical layer or MAC implementations, and therefore, they may transmit beacons and other packets when they should not.